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Call for Papers 

Winter 1989 USENIX Conference 

San Diego, California 
January 30 - February 3, 1989 


Papers are requested for formal review as 
candidates for inclusion in the three day tech¬ 
nical session at the 1989 Winter USENIX 
Conference. Papers that are accepted will be 
presented at the conference and published in 
the conference proceedings. The technical ses¬ 
sions provide a forum for the presentation of 
new research and development related to or 
based upon the UNIX operating system. 

Suggested topics include (but are not 
limited to); 

• Performance analysis and tuning 

• New User Interfaces and Applications 

• System and Network Security 

• Networking and Distributed Services 

• RISC versus CISC in UNIX 

• Software and System Management tools 

• Standards 

• Graphics and Electronic Publishing 

• Evolution of UNIX for the I990’s 

All papers should describe new and 
interesting work. Acceptance or rejection of a 
paper will based completely on the work 
submitted at the deadline. Submitted papers 
should consist of a 100 to 300 word abstract in 
addition to the main body of the paper. 
Extended abstracts will be conditionally 
accepted but full papers are preferred. Papers 
accepted on extended abstracts that do not 
meet the promise of the abstract will be 
rejected. Each paper should discuss how this 
work relates to prior work and provide 
sufficient detail in the presentation of back¬ 
ground material and work to allow referees to 
perform a consistent comparison to other 
submitted papers. Concise references of 
related work should also be included as 
appropriate. Full papers should be 6-12 single 
spaced typeset pages and include any abstract, 
references, or illustrations. For the review 
process you should submit the highest quality 
copy you can create. Laser printer output is 
recommended. The exact format for final 
papers will be sent to authors of accepted 
papers. 


Four hard copies and one electronic copy 
of each submitted paper must arrive no later 
than October 7, 1988; this is an absolute dead¬ 
line. Papers received after that date will not 
be considered. Papers which clearly do not 
meet USENIX’s standards for applicability, 
originality, completeness or page length may 
be rejected with no review. Authors will 
receive official notification no later than 
November 4, 1988, and final papers are due by 
December 5,1988. 

Please contact one of the program chairs if 
additional information is required: 

Greg Hidley, (619) 534-6170 
Keith Muller, (619) 534-4062 

They may be also be reached at 
sdusenix@ucsd.edu. 

Send technical program submissions to: 

Greg Hidley 
CSE Dept. C-014 

University of California, San Diego 
La Jolla, CA 92093 

Bitnet: sdusenix(a)ucsd 

Internet: sdusenix@ucsd.edu 
uucp: ucbvax!ucsd!sdusenix 

The program committee includes: 

Rick Adams Center for Seismic Studies 
Keith Bostic UC Berkeley 
Todd Brunhoff Tektronix 

John Chambers University of Texas, Austin 
Lori Grob NYU 

Andrew Hume AT&T Bell Labs 

Thomas Narten Purdue University 
Don Seeley University of Utah 

Melinda Shore Frederick Cancer 
Research Facility 

Gene SpafFord Purdue University 
Henry Spencer University of Toronto 
Avadis Tevanian NeXT 

Karen White Pyramid 
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UNIX Security Workshop 

Marriott Hotel 
Portland, Oregon 

August 29-30, 1988 


Matt Bishop is chairman for the UNIX 
Security Workshop to be held in Portland, 
OR, on Monday and Tuesday, August 29th 
and 30th, 1988. This workshop will bring 
together researchers in computer security 
dealing with UNIX and system administra¬ 
tors trying to use UNIX in environments 
where protection and security are of vital 
importance. It is believed that these peo¬ 
ple repeatedly battle many of the same 
problems and can share their unique solu¬ 
tions to some problems in order to avoid 
duplication of effort in making UNIX 
secure enough for their needs. It is 
intended that each participant will briefly 
present unique attributes of his/her 
environment and/or research and 
contribute a short (five minute) discussion 
(and paper) detailing some solution from 
their environment or work. 

Some topics to be considered include: 
password security (password file integrity, 
enforcing choice of a safe password, spot¬ 
ting and handling crackers), network 
security (problems arising from logins over 
an unprotected Ethernet, containing a 
break-in to one machine in a networked 
environment), file system security (audit¬ 
ing packages, security in an NFS environ¬ 
ment), new designs to obtain C-level (or 
better) certification, making existing UNIX 
systems more secure, and locating and 
fixing UNIX security problems. 


This gathering will follow a 
“workshop” format rather than a “paper 
presentation” format. The workshop 
chairman will schedule sessions which 
have related discussions and papers. It is 
anticipated that some sessions will include 
all 60-100 participants; some may require 
breaking into smaller groups. 

For further details on the workshop: 

Matt Bishop 

Dept, of Mathematics and Computer Science 
Bradley Hall 
Dartmouth College 
Hanover, NH 03755 

(603) 646-3267 

(ihnp4,decvax}!dartvax!bear!bishop 

bishop%bear.dartmouth.edu@relay.cs.net 

For details about registration, contact 
the USENIX Conference Office: 

(uunet,ucbvax} lusenixljudy 
(213) 592-3243 
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Workshop on UNIX and Supercomputers 

Westin William Penn Hotel 
Pittsburgh, Pennsylvania 

September 26-27, 1988 


A large number of supercomputers are now or will in the future be running UNIX as 
their primary operating system. This is the first workshop to consider the general problems 
of running UNIX on supercomputers, and will cover topics both practical and abstract. 
Areas of specific interest include but will not be limited to: 

Systems administration 
Archiving 
Scheduling 
File systems 

Networking and network protocols 
Job batching systems 
Monitoring performance/parallelism 
Programming languages and environments 
Fast file I/O 

Shared memory management 
IPC 

Very large files 
Checkpoint-restart 

The workshop will include both shorter presentations and full-length papers, and there 
will also be tours of Pittsburgh Supercomputing Center and Westinghouse Energy Center 
facilities and a reception at the Pittsburgh Supercomputing Center. Workshop proceedings 
will be available at the Workshop. 


For further details on the workshop, contact one of the Program Co-chairs: 


Lori Grob 

NYU Ultracomputer Research Lab 
715 Broadway, 10th Floor 
New York, NY 10003 

(212) 998-3339 
grob@lori.ultra.nyu.edu 


Melinda Shore 

Frederick Cancer Research Facility 
P.O. Box B, Building 430 
Frederick, MD 21701 

(301) 698-5670 
shore@ncifcrf.gov 


For information about registration, contact the USENIX Conference Office: 

(uunet,ucbvax} lusenixljudy 
(213) 592-3243 
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C++ Conference 

Denver, Colorado 
October 17-21,1988 


USENIX is pleased to host its first full 
C++ conference in Denver, Colorado, Monday 
through Thursday, October 17-20. A one-day 
limited-enrollment implementor’s workshop 
will follow the conference on Friday. 

Papers will be presented on all aspects of 
C++, including 

applications 

libraries 

new or improved implementations 
programming environments 
case studies 

We intend this conference to be interest¬ 
ing to a broad range of C++ users and poten¬ 
tial users. Even if you have never written a 
C++ program, you will probably be able to 
learn enough from the tutorials to follow the 
technical sessions. 

Tutorials, Monday and Tuesday 

The tutorial program is ideal for people 
who have been thinking about using C++ but 
haven’t had the opportunity to learn it. In 
addition, we expect to cover selected advanced 
topics for people who are already using C++. 

Technical sessions, Wednesday and Thursday 

One characteristic of C++ that stands out 
is the diversity of its applieations and users. 
They range from microcomputers to large 
systems, from graphics and databases to real¬ 
time process control, from single-programmer 
efforts to large projects. 

The technical sessions will present a cross 
section of this diverse and rapidly growing 
community. 


Implementor’s Workshop, Friday 

This small workshop, to be held in a 
difierent venue, is intended for people who are 
actively involved in C++ implementation. 
The workshop fee covers hotel accommoda¬ 
tions for Thursday and Friday nights, meals 
through Friday lunch, and round-trip transpor¬ 
tation leaving Denver after the main technical 
sessions and returning Saturday morning. 

The workshop is primarily for speakers at 
this and last year’s C++ meetings. If space 
permits, a few others will be admitted. If you 
don’t want to speak at the conference, but 
wish to attend the workshop, let us know. 

Program Committee 

Andrew Koenig, AT&T, chair 

Keith Gorlen, National Institutes of Health 

Mark Linton, Stanford University 

Richard Myers, Apple Computer 

Peggy Quinn, AT&T 

Mark Rafter, University of Warwick 

Michael Tiemann, MCC 

Direct all queries about the technical 
program to: 

Andrew Koenig 
Room 4N-R12 
AT&T Bell Laboratories 
184 Liberty Comer Road 
Warren, NJ 07060-0908 
ark@europa.att.com 
{attmail,research}!ark 
+ 1 201 5804127 (FAX) 

+ 1 201 580 4883 (last resort) 

For details about registration, contact the 
USENIX Conference Office. 


6 


July/August 1988 


Volume 13, Number 4 



;login: 


Call for Papers 

Workshop on Large Installation Systems Administration 

Monterey, California 
November 17-18, 1988 

In light of last year’s successful workshop on Large Installation Systems Administration, 
Alix Vasilatos will again be chairing a workshop on this subject in Monterey, CA on Thurs¬ 
day and Friday, November 17th and 18th, 1988. There is demonstrable benefit in bringing 
together system administrators of sites with 100 or more users (on one or more processors) 
to compare notes on solutions that they have found for a variety of common problems. 
These include but are not limited to: 

Large file systems (dumps, networked file systems) 

Password file administration 

Large mail system administration 

USENET/News/Notes administration 

Heterogeneous environments (mixed vendor and/or version) 

Load control and batch systems 
Monitoring tools 

Software release to multiple systems 
Output device management 

We are particularly interested in technical solutions to problems involving changes 
which directly affect users. 

The workshop will focus on short papers and presentations. Please submit (electroni¬ 
cally, to alix@athena.MIT.EDU) a one or two page single-spaced summary describing the 
solution to a problem. Include a description of the unique characteristics of the site, an out¬ 
line of the problem, and a description of the solution (detailed enough that fellow adminis¬ 
trators can implement it). Workshop proceedings will be available at the workshop. 

The deadline for submissions is September 15, 1988. For further details about the 
workshop, contact: 

Alix Vasilatos 
MIT Project Athena 
E40-357 

1 Amherst Street 
Cambridge, MA 02139 

(617) 253-0121 
alix@athena.MIT.EDU 

For details about registration, contact the USENIX Conference Ofl&ce. 
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Future Events 


UNIX Security Workshop 
Portland, OR, Aug. 29-30,1988 

The Program Chair is Matt Bishop of 
Dartmouth College. See page 4. 

AUUG Spring Conference 
Melbourne, Sept. 13-15,1988 

For information, write Tim Roper at 
uunet!munnari!labtam.oz!timr 

UNIX and Supercomputers Workshop 
Pittsburgh, PA, Sept. 26-27,1988 

Program Chairs are Melinda Shore of the 
Frederick Cancer Research Facility and Lori 
Grob of New York University. See page 5. 

EUUG Autumn Conference 
Portugal, Oct. 3-7,1988 

C-I-+ Miniconference 
Denver, CO, Oct. 17-21,1988 

The Program Chair is Andrew Koenig of 
AT&T. See page 6. 


Large Installation 
Systems Administration II 
Monterey, CA, Nov. 17-18,1988 

The Program Chair is Alix Vasilatos of 
MIT’s Project Athena. See page 7. 

USENIX 1989 Winter Technical Conference 
San Diego, Jan. 30-Feb. 3,1989 

See page 3. 

EUUG Spring Conference 
Brussels, Apr. 10-14,1989 

Long-term USENIX Conference Schedule 

Jan 30-Feb 3 ’89 Town & Country Inn, San Diego 

Jun 12-16 ’89 Hyatt Regency, Baltimore 

Jan 22-26 ’90 Omni Shoreham, Washington, DC 

Jun 11-15 ’90 Marriott Hotel, Anaheim 

Jan 21-25 ’91 Dallas 

Jun 10-14 ’91 Opryland, Nashville 

Jan 20-24 ’92 Hilton Square, San Francisco 

Jun 8-12 ’92 Marriott, San Antonio 


EUUG Autumn Conference 

Portugal 

October 3-7, 1988 

The Autumn ’88 European UNIX systems User Group Technical Conference will be held in 
southern Portugal. The theme of the conference is “New Directions for UNIX.” Technical tutorials 
will be held on October 3 and 4, followed by the three day conference. 

For further information about this and future EUUG events, contact the Secretariat. 


Secretariat 

EUUG 
Owles Hall 
Owles Lane 

Buntingford, Herts. SG9 9PL UK 

Phone: (+44) 763 73039 
Fax: (+44) 763 73255 (G2) 

Email: euug(Sinset.uucp 


Tutorial Officer 

Neil Todd 
1ST 

60 Albert Court 
Prince Consort Road 
London SW7 2BH UK 

Phone: (+44) 1 581 8155 
Fax: (+44) 1 581 5147 (G3) 

Telex: 928476 ISTECH G 
Email: neil(®ist.co.uk 


Programme Chair 

Peter Collinson 
Computing Laboratory 
University of Kent 
Canterbury, Kent CT2 7NF UK 

Phone: (+44) 227 764000, x7619 
Email: pc@ukc.ac.uk 
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Charge Number Accounting Without Kernel Modifications 

Paul E. McKenney 

SRI International 
Computer Systems & Services 


ABSTRACT 

The Golden Age of timesharing may be over, but there still are some hosts that must 
perform resource usage accounting. 

There have been many charge number accounting schemes implemented on UNIX, 
however, they typically require modifications to the UNIX kernel and to system programs 
such as login. 

Sri-unix had been running such a system for a number of years, but it was becoming 
very expensive to maintain, partly due to the age of the code and the number of program¬ 
mers who had modified it, but also because the modifications had to be reinstalled into each 
new release of the operating system. Therefore, we at SRI decided to rewrite the accounting 
system so that it would run on a vanilla BSD system (without modifications to the kernel or 
to systems programs). This project was successful; the resulting accounting system has been 
running on sri-unix for over a year. 

This paper will give an overview of the implementation, features, and limitations of 
this system, and will discuss some features of UNIX that helped (and hindered!) its 
development. 


1. Introduction 

Sri-unix is a “central” machine that is 
owned by SRI as a whole. Its continued 
existence is justified only by the willingness of 
its users to pay for the privilege of using it. In 
this day of personal computers and worksta¬ 
tions, it might be helpful to list some reasons 
why people would want to use a centrally 
located super-mini: 

• Low up-front cost. 

• Availability of user consultants. 

• Disk backups and other administrative 
chores performed by central staff. 

• Good network connectivity that might be 
expensive to reproduce elsewhere. 

Most of sri-unix’s users fall into these 
categories: 

• Mail and network news readers. These 
users would probably be satisfied with a 


normal accounting system, as they typically 
use a single charge number for all of their 
work. 

• Programmers. Again, these users would 
probably be satisfied with a normal accounting 
system. 

• Technical writers. These users need 
charge number accounting, since they typically 
prepare reports and proposals for many ongo¬ 
ing projects. Furthermore, these users wanted 
to be able to change charge numbers in mid¬ 
session, as logging off of and onto a busy 
system can be time-consuming. 

While there are relatively few technical 
writers on the system, the technical writers 
make much heavier use of the system than 
most other users do. They thus make a much 
heavier contribution to the system’s revenues 
than do the other users. Suffice it to say that 
we were more than willing to implement an 
accounting system to make life easier for them. 
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2. The Old Accounting System 

The old accounting system did charge 
number accounting that was based on the 
standard System V accounting system [2]. It 
billed for connect time, CPU time, disk space, 
and printer usage. Connect time and CPU 
time were billed at a lower rate during non¬ 
prime time and on holidays, and could be 
billed to different charge numbers (at the 
user’s discretion) on a session-by-session basis. 
Disk space and printer usage were billed at a 
flat rate to the user’s default charge number. 

The old system had the following draw¬ 
backs: 

• It had been modified over the years by a 
legion of programmers. The code was very 
difficult to read and maintain, and had 
accumulated an annoying number of 
idiosyncrasies and bugs. 

• It required users to log out and back in to 
change their charge number. This mis-feature 
did not make the technical writers happy. 

• It relied on a specially modified version of 
login to collect and record the charge number 
information. This modification had to be 
reapplied every time the operating system was 
upgraded, which diverted scarce systems 
programming resources from other projects 
and scarce budgetary resources to source 
license renewals. 

• There was no invoicing to the users, thus 
they were unsure of how much money they 
were spending until their charges worked their 
way through SRI’s main MIS system some 
weeks later. 

3. Requirements for the New 
Accounting System 

The new accounting system was required 
to: 

• Run on a vanilla BSD 4.2 version of UNIX. 
No modifications to the kernel or to systems 
programs were allowed. 

• Charge for connect time, CPU time, disk 
space, and printer usage. 

• Bill CPU and connect time at a lower rate 
during non-prime time and on holidays. 


• Allow the user to specify a charge number 
at any time during a login session, and have all 
subsequent connect and CPU time used during 
that session billed to that charge number. 

• Maintain lists of valid charge numbers. 
Each valid charge number must have a list of 
users who are permitted to use it. A separate 
charge number list must be kept for each 
UNIX group, and it must be possible to 
designate a user to be the group administrator 
for a given group. A group administrator must 
be able to modify the list of valid charge 
numbers for his group. The supervisor for a 
group is usually designated as that group’s 
administrator. 

• Produce per-command and per-user usage 
reports each week. 

• Produce a billing tape each week that can 
be used as input into SRI’s MIS system. 

• Send weekly invoices to users, at their dis¬ 
cretion. A user should also be able to specify 
that his invoice should be sent to someone else 
(e.g., his supervisor). 

• Allow a user to see how much the current 
session has cost so far. 

• Of course, the system should run with as 
little human intervention as possible. 

4. The User’s View of the New 
Accounting System 

4.1. Setting the Charge Number 

The setcharge program is the normal 
user’s main interface to the accounting system. 
This program may be run at any time during a 
login session. It will query the user for a 
charge number, possibly offering a default. 
The charge number entered by the user is 
checked against a list of valid charge numbers 
for that user. If the charge number is 
accepted, all subsequent CPU and connect time 
for the current login session will be billed to 
that charge number. 

If the user never runs the setcharge 
program, the session will be billed to his 
default charge number. “The accounting 
system always gets its money.” 
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4.2. Weekly Invoices 

A user can get weekly invoices automati¬ 
cally mailed to him by placing an empty file 
named .InvoiceWeekly into his home directory. 
He may also place a list of mail addresses into 
the .InvoiceWeekly file. This will cause weekly 
invoices to be mailed to each address in the 
list. 

For example, suppose that Mary is Peter’s 
supervisor, and that she wants to see his 
weekly invoices. If Peter places the following 
into his .InvoiceWeekly file: 

peter 

mary 

they will both get a copy of Peter’s weekly 
invoices. 

4.3. Cost of Current Session 

A csh script named SessionCost (based on 
the csh time command) may be sourced to 
determine the connect and CPU charges 
incurred so far for the current session. The 
following is an example of SessionCost's 
output: 

CPU and connect cost for session exclud¬ 
ing running background processes: 

$1.02 CPU, $4.83 Connect, $5.85 Total 

Since UNIX does not record the resource usage 
of a process until the process terminates, the 
CPU time printed by the SessionCost 
command does not include usage by processes 
still running in the background. Therefore, 
users should not be running any background 
jobs when using SessionCost to determine the 
cost of running a program. 

4.4. Charge Number Validation 

Each UNIX group has its own list of valid 
charge numbers, and its own set of lists of 
users who are allowed to bill to each of those 
charge numbers. The system administrator 
may designate a user as the administrator for a 
group. 

The group administrator can run the 
chacct program to add and delete charge 
numbers for the group, and to specify which of 
the users in that group will be allowed to use 
each charge number. The group administrator 


can also designate a default charge number for 
each user in his group. All of a user’s disk and 
printer usage is billed to his default charge 
number. 

5. The System’s View of the New 
Accounting System 

This section will concentrate on how the 
accounting system associates CPU and connect 
time usage with the proper charge number. 

The setcharge program records charge 
numbers onto the file /usr/adm/chgacct. The 
format of each chgacct record is as follows: 


Position 

Field Name 

Description 

0-7 

utjine 

Terminal line name 

8-15 

ut.name 

User name 

16-31 

ut_host 

Charge number 

32-35 

ut_time 

Time of eharge 
number change 


The astute reader may have noticed that this is 
really a utmp record with the charge number 
placed into the ut_host field (which normally 
contains the name of the remote host for 
remote login sessions). Stealing the utmp 
record format allows all the utilities that 
currently work with the /etc/wtmp file to be 
used on the /usr/adm/chgacct file. 

Each night, records from the pacct and 
wtmp files are correlated with the chgacct 
records, pacct records are output by the kernel 
each time a process terminates. They contain 
the user ID, the time the process was created, 
and the name of the process’s controlling 
terminal (as well as many other things, includ¬ 
ing the amount of CPU time that the process 
used), wtmp records are output by login (when 
a user is logged in) and by init (when a user 
logs out). They contain the user name, the 
terminal name, the name of the remote host 
(for telnet logins), and the time that the 
login/logout occurred. 

All three files are converted to ASCII so 
that they may be processed by the system sort 
utility. The wtmp reeords for the beginning 
and end of a login session are combined into a 
single record that represents the full login ses¬ 
sion. They are sorted by time within terminal 
line within user as shown in the following 
table: 
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User Name 

Terminal Name 

Time 

fred 

ttyi08 

08:43 

14:21 


ttyila 

07:30 

10:35 

12:54 

harry 

ttyi03 

16:36 


ttyill 

01:12 

05:42 


This ordering allows a simple merge program 
to associate the proper charge number with a 
given pacct or login session record. Of course, 
it may be necessary to split a login session 
record and associate each of the pieces with a 
different charge number. It is not necessary to 
do this with pacct records because each process 
is billed to the charge number in effect when 
that process was created. 

Note that this method of assigning charge 
numbers to pacct records requires the user be 
careful when running shell scripts in the back¬ 
ground. If the user starts up such a script, 
then changes the charge number, any processes 
started by the script after the charge number 
change will be billed to the new charge 
number. 

6. Help and Hindrance from UNIX 

The accounting system benefitted from the 
concepts of pipes, filters, and shell scripts in 
much the same way that many other applica¬ 
tions have in the past. 

The following sections describe some of 
the problems that UNIX presented. 

6.1. Time Base 

There is no absolutely trustworthy time 
base in UNIX, as the time of day can be 
changed at any time by anyone with super-user 
privileges. Since much of the billing is based 
on elapsed times, an accurate time base is very 
important to the accounting system. 

The date program does leave evidence of 
date changes in the /etc/wtmp file, but it is not 
always possible to correlate these change 
records with the timestamps in files created by 
the accounting system. For example, if the 
time is set back five minutes at 8:30, then there 
will be two different 8:27s. How is the poor 


application program to tell which of the two 
possible 8:27s is meant? 

Our work-around for this problem was 
straightforward - we prohibit setting of the 
date while in multi-user mode. However, it 
would be much more convenient for our 
operators and our users if we could allow the 
date to be changed while in multi-user mode. 
This could be done more easily if there was a 
counter that was faithfully incremented with 
the passage of time, independent of the the 
time-of-day clock (perhaps an 
ITIMER_MONOTONIC?). 

Note that an accurate time base is 
important to any program that needs to make 
elapsed-time measurements, including data 
collection programs and real-time systems. 

6.2. Single-precision awk 

awk keeps its numbers in single-precision 
floating-point variables. This means that you 
cannot do arithmetic on time.ts in awk. 
(Note that this has been fixed by some 
vendors; I applaud them.) 

We worked around this problem by writ¬ 
ing more C programs than originally planned, 
with attendant schedule slippage. 

6.3. Explicit Support for Charge Numbers 

Explicit support for charge numbers in the 
kernel would make this whole exercise trivial 
(aside from the maintenance of the kernel 
code). [ 1 ] took this approach. 

The printer spooling system and the disk 
quota system also do not know about charge 
numbers. An accounting system that needed 
to do charge number accounting for prin tin g 
and for disk usage could benefit from a change 
in this situation. 
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ABSTRACT 

In distributed system environments, a variety of administrative environments {system 
images) can be presented, reflecting different user requirements and administrative 
objectives. One of the most important system images is the so called “single system image.” 
This paper provides a context and definition for single system image. It describes an 
effective approach to collecting multiple UNIX systems into a single system image, based on 
simple use of remote mounts at fine granularities, including individual files. The approach is 
designed to allow for replication of administrative files, e.g., /etc/passwd, and graceful 
reconfiguration of the system to accommodate planned outages and respond to unplanned 
outages. Experiences with this approach and AIX^ Distributed Services are summarized. 


Introduction 

In a distributed system environment, 
individual machines usually perform roles as 
servers (file, print, name, ...) and/or clients. 
Subsets of machines may be associated into 
administrative groups or the associations 
between machines may remain primarily pair¬ 
wise and ad hoc. Figure 1 illustrates a typical 
software development environment. Some 
machines provide services to all other 
machines in the organization, e.g., network 
news, source control, special devices, etc. 
Some machines are administered directly by 
their owners and have only loose associations 
with other machines, e.g., the organization 
wide servers. Many of the other machines are 
collected into single system images, based on 
suborganizations. In the figure, single system 
images are represented by dashed boxes, 
intended to suggest “virtual” laboratories, 
virtual floors of a building, or virtual build¬ 
ings, as appropriate to the organization. (It is 
likely that the association of the machines into 
single system images will be based on organi¬ 
zational functions and boundaries, not physi¬ 
cal boundaries.) Within a single system image, 
machines are administered as a group, with 


t AlX is a trademark of International Business Machines 
Corporation. 


the intent that users can use any of the 
machines equivalently. There will be inherent 
exceptions to this, e.g., some machines will 
have color displays and others will have 
monochrome displays. And even where the 
hardware configurations are the same, the end 
users will usually be able to distinguish one 
machine from another, e.g., by querying a 
machine readable serial number. But a 
successful approach will give users the illusion 
that all the machines are the same under most 
circumstances: 

user accounts/passwords. A user can login to 
any of the machines using the same login 
name and the same password. Regardless of 
which machine is used, the user has the same 
home directory and execution environment. 
When the user changes his/her password, using 
the standard passwd command, the change is 
effective immediately on all machines in the 
single system image. When an administrator 
adds a new account, this is done once for all 
the machines. 

availability. Even though one or more of the 
machines is unavailable, the rest of the 
machines are still able to function together and 
present the same system image, except for 
resources which exist only on unavailable 
machines. A machine which cannot connect 
to other machines is still usable. 
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Figure 1: Associations of machines 


administered services. System wide functions, 
e.g., print and mail service, function the same 
from machine to machine. If mail is sent to a 
particular user, it can be seen/handled on any 
of the machines. 

This is not an exhaustive list, but is 
intended to be indicative. Wherever possible, 
the a dminis trator should view the collection of 
machines as if it were one machine and use 
the same procedures that would be used on a 
single machine. We will use the above 
characteristics as an operational definition of 
“single system image” and discuss an approach 
which we believe is effective in meeting the 
definition. 

Distributed Services (DS) provides 
distributed operating system capabilities for 
the AIX operating system. These include 
distributed file services with local/remote 
transparency, distributed interprocess 
communication and a number of 
administrative services. For background infor¬ 
mation on DS, see Sauer et al [1,2,3] and 


Levitt [4]. One of the design goals of DS was 
to provide support for mixed administrative 
environments, such as the one depicted in Fig¬ 
ure 1, using the same protocols and convenr 
tions across the administrative environment! 
One of the cornerstones of this administrative 
flexibility is a general remote mount model. 
The focus of this paper is to show how the 
features of this remote mount model can be 
used to simply and effectively present a single 
system image. We first describe some of the 
characteristics of the DS mount model, then 
describe the approach to single system image, 
and finally discuss some additional related 
topics. 

Distributed Services Mount Model 

Distributed Services uses “remote 
mounts” to achieve local/remote transparency. 
A remote mount is much like a conventional 
mount in the UNIX operating system, but the 
mounted filesystem is on a Afferent machine 
than the mounted-on directory. Once the 
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remote mount is established, local and remote 
files appear in the same directory hierarchy, 
and, with minor exceptions, file system calls 
have the same effect regardless of whether files 
(directories) are local or remote.' Mounts, 
both conventional and remote, are typically 
made as part of system startup, and thus are 
established before users login. Additional 
remote mounts can be established during 
normal system operation, if desired. 

Conventional mounts require that an 
entire file system be mounted. Distributed 
Services remote mounts allow mounts of 
subdirectories and individual files of a remote 
filesystem over a local directory or file, 
respectively. Fine granularity mounts are use¬ 
ful in configuring a single system image. For 
example, a shared copy of /etc/passwd may be 
mounted over a local /etc/passwd without hid¬ 
ing other, machine specific, files in the /etc 
directory. Use of mounts at a fine granularity 
is key to this approach to single system image. 

Virtual File Systems 

The Distributed Services remote mount 
design is based on the Virtual File System 
approach used with NFS [5,6]. This approach 
allows construction of essentially arbitrary 
mount hierarchies, including mounting a local 
object over a remote object, mounting a 
remote object over a remote object, mounting 
an object more than once within the same 
hierarchy, mount hierarchies spanning more 
than one machine, etc. The main constraint is 
that mounts are only effective on the machine 
performing the mount. 

In conjunction with using the Virtual File 
System concept, we necessarily have replaced 
the traditional nameiQ kernel function, which 
translated a full path name to an i-number, 
with a component by component lookupQ 
function. lookupQ is used both for local and 
remote path name resolution. The arguments 
to lookupQ are a file handle representing a 


1. The traditional prohibition of links across devices 
applies to remote mounts. In addition, Distributed 
Services does not support direct access to remote special 
files (devices) and the remote mapping of data files using 
the AIX extensions to the shmatQ system call. Note that 
program licenses may not allow execution of a remotely 
stored copy of a program. 


directory and the name of a component to be 
found in that directory. lookupQ returns a 
handle for the component, if found. A handle 
is effectively a pointer to the on-disk inode for 
the corresponding object and a generation 
number for that inode. The generation 
number is used for subsequent validity tests. 

When a client successfully requests a 
mount from a server, it receives a handle for 
the object it is mounting and stores it in its 
mount table. When the client is parsing a file 
path name, e.g., for openQ, and encounters the 
mounted object, the handle is given to the 
server as an argument in the lookupQ remote 
procedure call. Typically, the mounted object 
is a directory, and the server will look up an 
object within that directory. 

For example, let us suppose that a client 
mounts server’s /B over /a/b. The client then 
opens /a/b/c. When the client gets to b/c, it 
passes the handle for b and the component c to 
the server, requesting the server to look up and 
return a handle for c that can be used in the 
actual openQ call. The server will return a 
handle for /B/c. 

For fine granularity mounts, the string 
form of the file name component is returned, 
along with the file handle of the (real) parent 
directory. This alternative to using the file 
handle for the mounted file allows replacement 
of the mounted file with a new version without 
loss of access to the file (with that name). (For 
example, when /etc/passwd is mounted and the 
passwd command is used, the old file is 
renamed opasswd and a new passwd file is 
produced. If we used a file handle for the fine 
granularity mount, then the client would con¬ 
tinue to access the old version of the file. Our 
approach gives the effect, presumably 
intended, that the client sees the new version 
of the file.) 

There are several points to notice here. 
First, this approach is stateless in that the 
server can be recycled (e.g., powered off and 
on) and the handle(s) given to the client(s) 
performing a mount(s) is still valid, so the 
mount need not be repeated. This is true 
because the handle refers to an on-disk 
structure, not an in-memory structure. 
Second, the path resolution process must 
necessarily ignore mounts on the server, since 
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these are not reflected in the on-disk structures 
and are not necessarily repeated when the 
server is recycled. Third, as an immediate 
consequence, the client must explicitly perform 
all mounts “for itself,” since it does not “see” 
mounts performed by the server. 

Inherited Mounts 

In constructing a single system image of 
UNIX systems, it is desirable, if not necessary, 
to preserve the traditional directory hierarchy 
and conventions. All the machines in the sin¬ 
gle system image must see the same instances 
of /etc/passwd, /etc/hosts, ..., home direc¬ 
tories, spool directories for mail, and so forth. 
However, it is also desirable/necessary to be 
able to access local equivalents of these 
files/directories so that they may be kept up to 
date with the shared copies. For example, 
/etc/passwd refers to a shared copy of the file, 
and /native/etc/passwd refers to the unshared 
local version. In general /native/a/b/... is 
established as the path to the local instance of 
/a/b /.... 

Without the concept of inherited mounts, 
discussed below, this implies that each 
machine would have to be doubly configured 
for its local (device) mounts. E.g., if / (root), 
/m, and /usr are on partitions /dev/hdO, 
/dev/hdl, and /dev/hd2, then the desired 
mounts could be achieved by the commands: 

mount /dev/hdl /u 
mount /dev/hd2 /usr 
mount / /native 
mount /u /native/u 
mount /usr /native/usr 

Alternatively, the mount profile 
{/etc/filesystems in AIX) would contain an 
entry for each of these mounts. If another 
disk was added to hold /usr/src, then two 
profile entries would be needed, one for 
mounting /usr/src and one for mounting 
/native/usr/src. 

Distributed Services implements inherited 
mounts on top of virtual file systems. There is 
a mntctlQ system call and corresponding 
remote procedure call. One of the options of 
mntctlQ is to query and return a list of all 
mounts currently in effect on a given server. 


The mount command in AIX supports a -i 
(inherited) flag which causes the query to be 
performed and the additional mounts to be 
made. For the above example, 

mount -i / /native 

would have the same net effect as the three 
separate mount commands for the /native 
subtree. When additional device mounts are 
configured, this single mount command still 
provides the desired effect of an aliased nam¬ 
ing path for the local instance of the file 
hierarchy. Additional examples of motivation 
for inherited mounts are given in [3]. 

Presentation of Single System Image 

Objectives 

• The configuration is managed by a few 
simple profiles. It should be easy to add/delete 
machines and users, and to make other 
configuration changes. 

• All of the machines in the single system 
image cluster should use exactly the same 
configuration files, i.e., there is no distinction 
between the profiles on the server for 
/etc/passwd and related files and the ones on 
the clients. 

• As a result of the above, it should be sim¬ 
ple to reconfigure to use a different server for 
the /etc files, either because of planned outages 
of the existing server or because of failure of 
the existing server. 

• Client machines should recognize when 
the server is unavailable, and switch to 
alternate copies of administrative files and 
other shared files. 

• Local replicated copies of the 
administrative files should be periodically 
updated, so that if there is an unplanned 
outage of the server, the other machines have 
up to date copies. 

• If a machine providing some of the home 
directories is unavailable, a user should dis¬ 
cover this immediately at login time, and and 
be able to either use an alternate home direc¬ 
tory or wait until the machine becomes avail¬ 
able again. 
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General Approach 

The discussion will focus on 
administrative files, e.g., /etc/passwd, and data 
files, e.g., home directory subhierarchies and 
mail spooling areas. Assuming, for the 
moment, a homogeneous processor 
architecture, executable files may be viewed 
between two extremes: (1) all of the machines 
in the cluster have full copies of the executable 
code, and so there is no sharing of executables, 
or (2) there is a single shared copy of each 
executable file. The first extreme has the 
potential for inconsistency among the multiple 
copies, administrative burden to ensure that 
inconsistent copies are not present, and waste 
of disk space for the redundant copies. The 
second extreme has the limitation that execut¬ 
ables will be unusable if the shared copy is not 
accessible. An administrator will typically 
choose a policy in between the extremes, e.g., 
that the kernel and the files in /etc and /bin 
are replicated, but that other executables are 
shared. The approach discussed below 
supports and allows flexibility in determining 
such policies. However, AIX and DS have 
other administrative mechanisms, known as 
“code serving” which address these policies in 
detail, so we focus on the administrative and 
data files. 

Where heterogeneous processor 
architectures are involved, the motivation for 
a separate mechanism for code serving is 
stronger, since the mechanisms below should 
not be used for sharing binary executables 
across different processor architectures. The 
files explicitly shared in the mechanisms 
described below are in ASCII format, and are 
suitable for sharing across heterogeneous 
processor architectures. Thus the mechanisms 
themselves will work across heterogeneous 
processor architectures. However, in the 
heterogeneous environment, machine 
boundaries are much more likely to be visible, 
e.g., due to byte order considerations in appli¬ 
cation data. More stringent requirements 
must be placed on application code in such an 
environment, if the illusion of a single system 
is to be preserved. 


Configuration Files 

/etc/adminserver. One machine is 
designated as the “administrative server” and 
is the machine that has the disk copies of the 
shared administrative files such as /etc/passwd. 
The administrative server can be changed 
while machines are in operation, as discussed 
below. The name of the administrative server 
is stored in /etc/adminserver, 

/etc/SSImachines, This file lists the names 
of all machines in the single system image 
(including the administration server). 

/etc/serverfiles. This file lists individual 
files that will be shared based on the 
administrative server’s copy. For example, 
this list might include 

/etc/passwd 

/etc/group 

/etc/motd 

/etc/qconfig 

(AIX printer configuration file) 

/etc/hosts 

/etc/hosts.equiv 

/etc/adminserver 

/etc/SSImachines 

/usr/adm/user.cfile 

(AIX adduser defaults) 

/etc/server.files 

/etc/server.dirs (see below) 

/etc/remounts.list (see below) 

/etc/ug.SSI 

(for id translations - see below) 

/etc/oug.SSI 

/etc/opasswd 

/etc/ogroup 

/etc/umountd.c 

(source for umountd - see below) 
/usr/adm/newuser.sys 

(AIX adduser defaults) 

/usr/adm/newuser.usr 

Though the list could be longer or shorter, 
roughly this set of files has been appropriate in 
our experience. 

/etc/server.dirs. This file lists directories, 
other than home directories, that will be 
shared based on the administrative server’s 
copy. Assuming that code serving is handled 
separately, this list might include 
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/usr/mail 

/usr/lib/news 

/usr/spool/news 

/usr/man 


If code serving is not handled separately, then 
/usr/bin, /usr/lib, ... might be added to this 
list. 

/etc/remounts.list. This file lists files and 
directories that will be unmounted when it is 
detected that the server is inaccessible and 
remounted when the server becomes accessible 
again. This is handled by the umountd 
daemon, discussed below. This list will be a 
subset of the combined lists in server.files and 
server.dirs, e.g., 

/etc/passwd 

/etc/group 

/etc/motd 

/etc/qconfig 

(AIX printer configuration file) 

/etc/hosts 

/etc/hosts.equiv 

/etc/adminserver 

/etc/remounts.list 

/usr/mail 

This is a subset of the combined list oriented 
toward normal operation when the 

administrative server is inaccessible. It is a 
subset because some operations, e.g., changing 
passwords, presumably will be deferred when 
the administrative server is inaccessible, and 
some directories, e.g., /usr/man and 

/usr/spool/news, are likely to be empty, except 

on the administrative server, and thus 

uninteresting when that machine is 
unavailable. 

/etc/ug.SSI, /etc/oug.SSI. DS provides 
general translation mechanisms for user and 
group id translation [1,2]. For machines 
within the cluster, there should be one to one 
translations, so that numeric id’s are the same 
on all machines in the cluster, but machines in 
the cluster may also need translations to other 
machines outside the cluster. ugSSI is used 
for a cluster wide definition of the translations. 
For brevity, we will not discuss the content of 
these files. 


Home Directories 

For the sake of simplicity, it is assumed 
that home directories’ path names have the 
form .../machine/user, where “machine” is the 
name of the machine where the home direc¬ 
tory is actually stored. Even though paths are 
of this form, users will see the same actual 
home directory on each machine of the cluster, 
e.g., in our environment, when user sauer is 
logged into machine d75, his home directory is 
still /u/auschs/sauer, since his home directory 
is stored on auschs. This is a minor sacrifice 
of transparency, since users usually do not use 
rooted paths to get to their home directories - 
their home directory is listed in /etc/passwd, 
so that is where they start, cd takes them back 
there, and the C shell “ notation is often used 
to get to other users’ home directories, e.g., 
cd^dale, Shipley has proposed a similar 
convention for sharing home directories [7J. 

Having paths of this form allows each 
machine to simply mount the home directories 
stored on other machines, e.g., 

mount -n auschs /u/auschs /u/auschs 
or, in general, 

for i in ‘cat /etc/SSImachines‘ 

do 

if [ $i != $myname ] 
then 

mount -i -n $i /u/$i /u/$i 
fi 

done 

This is a slightly simplified fragment from 
/etc/SSImounts, discussed below. 

Machine Initialization 

As init processing, after normal standalone 
initialization, e.g., fsck and device mounts, 
/etc/rc starts DS and then runs /etc/SSImounts. 
SSImounts runs in the background so that 
local operations can begin without server 
availability. SSImounts runs on all machines, 
including the adminserver. Following are 
simplified sketches taken from SSImounts. 
Error checks, touches and mkdirs for mount 
points, precautionary amounts, etc. are 
omitted. 
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Initial mounts from adminserver, updating 
local copies of files: 

if [ $myname != $adminserver ] 
then 

until mount -i -n $adminserver \ 

/native /$adminserver 
do 

sleep $delay 
done 

for i in ‘cat /etc/server.files‘ 
do 

cp -p /$adminserver$i $i 
mount -n $adminserver /native$i $i 
done 

for i in ‘cat /etc/server.dirs* 
do 

mount -i -n $adminserver /native$i $i 

if [ $i = Vusr/mair ] 

then 

/etc/movemail & # see below 
fi 

done 

fi 

Start /etc/umountd 

make umountd 
/etc/umountd & 

Update user/group ids. 

cmp /etc/ug.SSI /etc/oug.SSI 

if [ $? -ne 0 ] 

then 

dsldxprof -a -f /etc/ug.SSI 

if [ $? -eq 0 ] 

then 

cp -p /etc/ug.SSI /etc/oug.SSI 
fi 
fi 

Mount home directories. This is as indicated 
in the previous fragment, except that the 
mounts are retried asynchronously in the back¬ 
ground so that availability of any given 
machine doesn’t delay availability of home 
directories from other machines. 

Once these steps have been performed, 
then the machine has joined the single system 
image. 

/etc/movemail. Mail received while the 
administrative server is not available will be 
kept in the native spool directory, /usr/mail. 
movemail moves mail from the native spool 
directory to the shared spool directory when¬ 
ever the shared directory is mounted, either by 
SSImounts or remounts (see below). 


umountd 

The key remaining topic is the daemon 
umountd. umountd uses a polling loop, 
performing the following functions and then 
sleeping until repeating the functions. The 
default sleep time is 60 seconds. 

Detection of server inaccessibility, umountd 
attempts to open each of the files listed in 
/etc/server.files. If an open fails, umountd 
assumes the server is inaccessible and executes 
/etc/remounts, /etc/remounts unmounts aU of 
the files in /etc/remounts.list and then attempts 
to remount them, remounts will execute 
movemail after successfully remounting 
/usr/mail. {umountd runs on adminserver, but 
skips these steps.) 

Updating modified files, umountd determines 
whether any of the files in /etc/server.files have 
been updated. If so, umountd locks the server 
copy and updates the native copy, {umountd 
running on adminserver skips these steps.) 

Detection of configuration changes. If key 
configuration files, e.g., /etc/adminserver or 
/etc/server.files, have been updated, umountd 
execs SSImounts. SSImounts applies the 
changes and then starts a fresh version of 
umountd, as indicated above. 

There are subtleties of locking and timing 
which we omit for brevity. Starting with DS 
1.2, the source for umountd.c is included in the 
DS samples directory, along with the installa¬ 
tion documentation, installation command and 
so forth. 

Note the power of the above mechanisms. 
By simply changing the name of the server in 
/etc/adminserver, e.g., for a scheduled outage 
of the adminserver, the machines in the cluster 
will shift to the new adminserver in a couple 
of minutes, without rebooting any of the 
machines or otherwise significantly disrupting 
users. For an unscheduled server outage of 
significant duration, a switchover to a different 
server can be accomplished by changing the 
adminserver file on each of the other machines 
and rebooting them. In either case, scheduled 
or unscheduled, the original server can rejoin 
the cluster as a client when it is ready to rejoin 
the cluster, and then assume the server role 
again when its configuration files have been 
updated. 


Volume 13, Number 4 


July/August 1988 


19 



;login: 


Summary 

We believe this approach effectively meets 
the operational definition given in the 
introduction, in regard to user accounts, data, 
availability, and administered services. The 
mechanisms are designed to be simple to apply 
and administer, yet highly effective in present¬ 
ing the image of a single system. These 
mechanisms are complementary to the under¬ 
lying file system mechanisms of Distributed 
Services, and orthogonal to other enhance¬ 
ments such as the code server mechanisms. 
Thus the same underlying mechanisms are 
applied across the distributed environment, for 
example the abstraction of our software 
development environment depicted in Figure 

1. In addition, significant administrative flexi¬ 
bility is present, as suggested in the preceding 
paragraph. These concepts could be applied to 
other distributed file systems supporting fine 
granularity mounts. 
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Workstation, February 1986. 

7. M. Shipley, “The Virtual Home Environment,” 
UniForum 1988, Dallas, TX, February 1988. 


San Francisco Thanks 

The USENIX Association would like to thank all those who helped in setting up the terminal 
room in San Francisco - TELEBIT for loaning modems, Marc Teitelbaum, DEC & UCB, for providing 
terminals, as well as Jim Chapman, Howard Chu, Steve Gumming, Jeff Janock, Brian Kantor, Greg 
Noels, Landon Noll, Jeff Roth, Dick Smith, Alix Vasilatos, and Mike Williams for surveilling the 
room. 

Thanks to Eric Brunner of SRI for aiding in the Internet connection. (At least one person got 
through to England.) 

And finally, thanks to the students from UC Berkeley and to the others who helped make the 
conference run smoothly. 
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Publications Available 


The following publications are available 
from the Association Ofl&ce. Prices and 
overseas postage charges are per copy. 
California residents please add applicable sales 
tax. Payment must be enclosed with the order 
and must be in US dollars payable on a US 
bank. 


The EUUG Newsletter, which is published 
four times a year, is available for $4 per copy 
or $ 16 for a full-year subscription. 

The July 1983 edition of the EUUG 
Micros Catalog is available for $8 per copy. 


Conference and Workshop Proceedings 

Overseas Mail 


Meeting 

Location 

Date 

Price 

Air 

Surface 

USENIX 

San Francisco 

Summer ’88 

$20 

$25 

$5 

C++ Workshop 

Santa Fe 

November ’87 

20 

25 

5 

Graphics Workshop IV 

Cambridge 

October ’87 

10 

15 

5 

USENIX 

Wash. DC 

Winter ’87 

10 

25 

5 

Graphics Workshop III 

Monterey 

December ’86 

10 

15 

5 

Graphics Workshop I 

Monterey 

December ’84 

3 

7 

5 


C++ Tape 

The first 1988 USENIX software tape contains C++ software. It requires no AT&T nor UC 
license. It is being sent to all current Institutional and Supporting members of the Association. 

Individual members of USENIX who wish to obtain a copy of the tape may request it from the 
Association Office, which will then send the requestor a “Tape Release Form.” The form plus a 
check for $125 should be returned to the office, whereupon the tape will be sent out, postpaid in the 
US. Foreign individuals will be billed for the additional (air) postage/shipping. 

The tape, in tar format at 1600 BPI, contains: 

GNU C++ Version 1.21.0 (Michael Tiemann) 

OOPS (Keith E. Gorlen) 

Storage management class and String class... (Peter A. Buhr) 

Interviews 2.3 (Mark A. Linton) 

C++ Subroutines for string manipulation (Arthur Zemon) 

The tape is not available to non-members of the USENIX Association. 

♦ * ♦ 


If you are were an institutional member in 1987 and have not received your 1987 software 
distribution tapes, please contact the office. 


Volume 13, Number 4 


July/August 1988 


21 







;login: 


2.10BSD Software Release 


The “Second Berkeley Software Distribu¬ 
tion” (2.10BSD), produced by the Computer 
Systems Research Group (CSRG) of the 
University of California, Berkeley, is being 
distributed by the USENIX Association. It is 
available to all V7, System III, System V, and 
2.9BSD licensees for a price of $200. The 
release consists of two 2400 foot, 1600 BPI 
tapes (approximately 80Mb) and approximately 
100 pages of documentation. If you require 
800 BPI tapes, please contact USENIX for more 
information. 

Sites wishing to run 2.10BSD should be 
aware that the networking is only lightly 
tested, and that certain hardware has yet to be 
ported. Contact Keith Bostic at the address 
below for current information as to the status 
of the networking. As of August 6, 1987, the 
complete 4.3BSD networking is in place and 
running, albeit with minor problems. The 
holdup is that only the Interlan Ethernet 
driver has been ported, as well as some major 
space constraints. Note, if we decide to go to 


a supervisor space networking, 2.10 networking 
will only run on: 

11/44/53/70/73/83/84 
11/45/50/55 with 18 bit addressing 

If you have questions about the distribu¬ 
tion of the release, please contact USENIX at: 

2.10BSD 

USENIX Association 
P.O. Box 2299 
Berkeley, CA 94710 

+ 1 415 528-8649 
{uunet,ucb vax} lusenixioffice 

If you have technical questions about the 
release, please contact Keith Bostic at: 

{ucbvax,seismo} Ikeith 
keith@okeeffe.berkeley.edu 

-1-1 415 642-4948 

Keith Bostic 
Casey Leedom 


New Supporting Member 

At the San Francisco Technical Conference, the USENIX Association acquired its eighth 
supporting member: the Open Software Foundation (OSF) of Lawrence, MA. The Association is 
most grateful for the corporate support shown by OSF and the other supporting members: AT&T, 
Convex, DEC, mt Xinu, QMS, Sun Microsystems, and Sybase. 
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UUNET Communications Service 


The UUNET Communications Service is 
now^ one year old and has proven itself to be a 
success. UUNET is a non-profit communica¬ 
tions service that provides access to USENET 
news, UUCP mail, public domain software, 
and many standards. The UUNET computer is 
accessible by any computer running the UNIX 
operating system. With the purchase of a 
third party software package, any PC running 
MS-DOS can also access UUNET. 

The UUNET Communications Service 
came about because many people were having 
difficulty in accessing USENET, the worldwide 
network of UNIX users. When a USENET 
connection was found, it was often expensive 
to maintain, unreliable, or prone to 
unanticipated interruption when the remote 
computer was used for work rather than for 
USENET access. The USENIX Association 
funded the UUNET Communications Service 
to assist UNIX users in accessing the USENET 
network and in sending electronic mail to 
other UNIX users. 

UUNET, because of its mandate, has 
become the best connected UNIX computer in 
the world. It provides its subscribers with easy 
access to the USENET news and mail network 
and to other UNIX users. UUNET has been 
authorized to function as an ARPANET mail 
gateway. Gateways to other networks are 
being set up. UUNET is also the principal 
gateway to European, Australian, Asian, and 
South American UUCP sites. 

UUNET provides subscribers with UUCP 
access to an extensive archive of publicly 
available UNIX software. This includes the 
latest GNU software, all the ARPANET RFCs, 
the latest UUCP map information, the latest 
Kermit distributions, and the netlibd archives. 


Operationally, UUNET consists of a 16- 
processor Sequent B21 computer with 20 
dialup modems (12 accessible via an 800 
number), a T-1 connection, over one gigabyte 
of disk space, and a 56 KBPS dedicated 
connection to Tymnet. This system is 
dedicated to UUNET and has no function 
other than as a communications relay. Most 
subscribers access UUNET through the Tymnet 
X.25 public data network or via Telebit 
Trailblazer Plus modems. 

Because the UUNET Communications 
Service is non-profit, costs to subscribers can 
be kept very low. Most subscribers call in at 
night, taking advantage of the $4.00 per hour 
Tymnet oflf-peak rate. 

UUNET currently has over 360 subscribers, 
including individuals, universities, computer 
companies, banking and investment firms, and 
other companies. Many subscribers save a 
substantial sum of money by using UUNET 
rather than paying long distance charges to 
receive news and mail. 

For further information on the UUNET, 
provide your name and US postal address to 
the UUNET office at: 

{ucbvax,usenix}!uunet!uunet-request 

(703) 764-9789 

UUNET Communications 
P.O. Box 2685 
Fairfax, VA 22031 
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4.3BSD Manuals 


The USENIX Association now oflFers all 
members of the Association the opportunity to 
purchase 4.3BSD manuals.^ 

The 4.3BSD manual sets are significantly 
difierent from the 4.2BSD edition. Changes 
include many additional documents, better 
quality of reproductions, as well as a new and 
extensive index. All manuals are printed in a 
photo-reduced 6"x9" format with individually 
colored and labeled plastic “GBC” bindings. 
All documents and manual pages have been 
freshly typeset and all manuals have “bleed 
tabs” and page headers and numbers to aid in 
the location of individual documents and 
manual sections. 

A new Master Index has been created. It 
contains cross-references to all documents and 
manual pages contained within the other six 
volumes. The index was prepared with the aid 
of an “intelligent” automated indexing 
program from Thinking Machines Corp. along 
with considerable human intervention from 


Mark Seiden. Key words, phrases and 
concepts are referenced by abbreviated docu¬ 
ment name and page number. 

While two of the manual sets contain 
three separate volumes, you may only order 
complete sets. 

The costs shown below do not include 
applicable taxes or handling and shipping from 
the publisher in New Jersey, which will 
depend on the quantity ordered and the 
distance shipped. Those charges will be billed 
by the publisher (Howard Press). 

Manuals are available now. To order, 
return a completed “4.3BSD Manual 
Reproduction Authorization and Order Form” 
to the USENIX office along with a check or 
purchase order for the cost of the manuals. 
You must be a USENIX Association member. 
Checks and purchase orders should be made 
out to “Howard Press.” The manuals will be 
shipped to you directly by the publisher. 


Manual Cost* 

User’s Manual Set (3 volumes) $25.00/set 

User’s Reference Manual 
User’s Supplementary Documents 
Master Index 

Programmer’s Manual Set (3 volumes) $25.00/set 

Programmer’s Reference Manual 
Programmer’s Supplementary Documents, Volume 1 
Programmer’s Supplementary Documents, Volume 2 

System Manager’s Manual (1 volume) $10.00 

* Not including postage and handling or applicable taxes. 


4.2BSD Manuals are No Longer Available 


^ Tom Ferrin of the University of California at San Francisco, a former member of the Board of Directors of the USENIX 
Association, has overseen the production of the 4.2 and 4.3BSD manuals. 
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4.3BSD Manual Reproduction Authorization and Order Form 

This page may be duplicated for use as an order form 

USENIX Member No.:_ 

Purchase Order No.:_ 

Date: __ 

As a USENIX Association Member in good standing, and pursuant to the copyright notice as 
found on the rear of the cover page of the UNIX®/32V Programmer’s Manual stating that 

“Holders of a UNIX®/32V software license are permitted to copy this document, or any portion of it, as 
necessary for licensed use of the software, provided this copyright notice and statement of permission 
are included,” 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and provide 
me with such copies of the Berkeley 4,3BSD Manuals as I may request. 

Signed:_ 

Institution (if Institutional Member):___—-- 

Ship to 
Name: 


Phone: 

The prices below do not include shipping and handling charges or state or local taxes. All pay¬ 
ments must be in US dollars drawn on a US bank. 

4.3BSD User’s Manual Set (3 vols.) at $25.00 each = $- 

4.3BSD Programmer’s Manual Set (3 vols.) _ at $25.00 each = $- 

4.3BSD System Manager’s Manual (1 vol.) _ at $10.00 each = $„- 

Total _ $-- 

[ ] Purchase order enclosed; invoice required. 

(Purchase orders must be enclosed with this order form.) 

[ ] Check enclosed for the manuals: $._ 

(Howard Press will send an invoice for the shipping and handling charges and applicable taxes.) 

Make your check or purchase order out to “Howard Press” and mail it with this order form to: 

Howard Press 
c/o USENIX Association 
P.O. Box 2299 
Berkeley, CA 94710 


Phone: 


Billing address, if different: 
Name:__ 


for office use: m.v.: 


check no.: 


amt. rec’d: 
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Local User Groups 

The USENIX Association will support local user groups by doing an initial mailing to assist the 
formation of a new group and publishing information on local groups in ;login:. At least one member 
of the group must be a current member of the Association, 


CA - Fresno: the Central California UNIX Users 
Group consists of a Mwcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufresigordon 

CA - Los Angeles: the Los Angeles UNIX Group 
meets on the 3^** Thursday of each month in 
Redondo Beach. 

Drew Bullard (213) 535-1980 

{ucbvax,ihnp4) !trwrb!bullard 

MarcRies (213) 535-1980 

{decvax,sdcrdcf) !trwrb!ries 

CO - Boulder: meets monthly at different sites. 

Front Range UNIX Users Group 
USENIX Association Exhibit Office 
5398 Manhattan Circle 
Boulder, CO 80303 

John L. Donnelly (303) 499-2600 

{boulder,usenix) Ijohnd 

FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 

FL - Melbourne: the Space Coast UNIX Users 

Group meets at 8pm on the 3 ^^ Wednesday of each 
month at the Florida Institute of Technology. 

Alex Stover (305) 724-3962 

codas !lola!als 

Bill Davis (305) 242-4449 

bill@ccd.harrisxom 

FL - Orlando: the Central Florida UNIX Users 

Group meets the 3*^^ Thursday of each month. 

Mike Geldner (305) 862-0949 

codas!sunfla!mike 


Ben Goldfarb (305) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (305) 869-2462 

{codas, attmail)! mikel 

FL - Tampa Bay: the Tampa UNIX Users Group 
meets the Thursday of each month, alternately in 
Largo and Tampa. 

Scott Stone (813) 974-3307 

uflorida!usfvax2!stone, stone@usfedu 

Bill Hargen (813) 530-8655 

{codas,usfvax2}!pdn!hargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 

GA - Atlanta: meets on the 1^^ Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 

MI - Detroit/Ann Arbor: meets the 2"^ Thursday 
of each month in Ann Arbor. 

William Bulley (313) 995-6211 

web@applga.uucp 

Rich McGill (313) 971-5950 

rich@oxtrap.uucp 

Steve Simmons (313) 426-8981 

scs@lokkur. uucp 

MI - Detroit/Ann Arbor: dinner meetings the 
Wednesday of each month. 

Linda Mason (313) 855-4220 

niichigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 

MN - Minnetonka: meets the 1®^ Wednesday of 
each month. 

UNIX Users of Minnesota 
4732 Spring Circle 
Minnetonka, MN 55343 
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OK - Tulsa: 


Mark Colburn (612) 935-2688 

mark@ems.mn.org or ihnp4!meccts!ems!mark 


MO - St. Louis: 


St. Louis UNIX Users Group 

Plus Five Computer {Services 

765 Westwood, lOA 

Clayton, MO 63105 


Eric Kiebler 
ihnp4!plus5!sluug 

(314) 725-9492 

NE - Omaha: meets on the 2"^ Thursday of each 
month. 

/usr/group nebraska 

P.O. Box 44112 

Omaha, NE 68144 

Sukan Makmuri 
ihnp4!ugn!root 

(402) 422-8367 

New England - Northern: meets 

different sites. 

monthly at 

Emily Bryant 

Kiewit Computation Center 
Dartmouth College 

Hanover, NH 03755 

(603) 646-2999 

David Marston 

Daniel Webster College 

University Drive 

Nashua, NH 03063 

(603) 883-3556 

decvax! dartvax! nneuug-contact 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian 

Dept, of Computer Science 

Princeton University 

Princeton, NJ 08544 

(609) 452-6261 

pep@Princeton. EDU 


NY - New York City: 

Unigroup of New York 

G.P.O. Box 1931 

New York, NY 10116 


Ed Taylor 

{attunix,philabs}!pencom!taylor 

(212) 513-7777 


New Zealand: 

New Zealand UNIX Systems User Group 
P.O. Box 13056 
University of Waikato 
Hamilton, New Zealand 


Pete Rourke 
$USR 

7340 East 25^^ Place 
Tulsa, OK 74129 


PA - Philadelphia: the UNIX SIG of the 
Philadelphia Area Computer Society (PACS) meets 
the morning of the 3rd Saturday of each month at 
the Holroyd Science Building, LaSalle University. 

G. Baun, UNIX SIG 
do PACS 
Box 312 

La Salle University 
Philadelphia, PA 19141 

{inhp4,cbosgd,rutgers}!{bpa,cbmvax}! 
temvaxipacsbb! {gbaun,whutchi) 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX - San Antonio: the San Antonio UNIX Users 
(SATUU) meets the 3^^ Wednesday of each month. 

William T. Blessum, M.D. (512) 692-0977 

7950 Floyd Curl Dr. #102 
San Antonio, TX 78229-3955 
{gatech,ihnp4} !petro!bles!wtb 

The local uucp network “postmaster” is: 

Bruce Andreen (512) 656-3053 

{gatech,ihnp4} !petro!bruce 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
6641 East Mercer Way 
Mercer Island, WA 98040 

uw-beaver!tikal!camco!bill 


Washington, D.C.: meets the Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 333 
Vienna, VA 22180 

Samuel Samalin (703) 448-1908 
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USENIX Association 

P.O. Box 2299 
Berkeley, CA 94710 


First Class Mail 


FIRST CLASS MAIL 
U.S. POSTAGE PAID 
Berkeley, CA 
Permit No. 993 


Charge Number Accounting 
Without Kernel Modifications 

Presenting a Single System Image 
with Fine Granularity Mounts 

C++ Tape 

Conferences, Workshops, Publications 


Change of Address Form 

Please fill out and send the following form through the U.S. mail to the Association Office at the address above. 

Name:______ Member #:_ 

OLD:__NEW:____ 


Phone:_ 

uucp\ {uunet,ucbvax)! 






